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Abstract 

The  Royal  Netherlands  Army  (RNLA)  is  currently  developing  a  demonstrator  Battlefield 
Management  System  (BMS),  which  will  support  soldiers  by  displaying  and  distributing 
the  available  C2  information.  Throughout  the  entire  development  of  the  BMS,  the  future 
military  users  play  a  very  important  role.  There  is  frequent  contact  between  users  and 
developers  and  new  versions  of  the  BMS  are  presented  to  and  evaluated  by  users  every 
few  months.  The  development  consists  of  several  cycles,  while  users  are  involved  in 
nearly  every  step  in  each  cycle.  This  leads  to  commitment  of  the  user,  because  he  notices 
that  his  comments  are  taken  seriously  and  are  usually  implemented  in  the  next  version  of 
the  BMS.  This  user-centered  approach  has  worked  very  well  so  far  for  both  developers 
and  military  users.  Several  evaluations,  in  different  settings  and  environments,  have  been 
conducted  over  the  past  two  and  a  half  years.  This  paper  describes  two  of  them  in  more 
detail,  and  also  covers  the  user-centered  approach  that  was  taken  in  the  development  of 
the  BMS.  The  paper  explains  the  approach  that  was  chosen  by  the  RNLA,  and  discusses 
the  advantages  of  this  approach,  as  opposed  to  situations  where  users  are  not  involved  in 
the  development  of  C2  systems. 

1.  Introduction 

The  Royal  Netherlands  Army  (RNLA)  is  currently  developing  a  demonstrator  of  a 
Battlefield  Management  System  (BMS).  The  BMS  will  aid  soldiers  in  performing  their 
tasks  by  graphically  displaying  the  available  C2  information  concerning  own  troops, 
enemy  troops,  terrain  features  and  different  plan  overlays.  In  order  to  do  so,  a  typical 
BMS  will  consist  of  several  hardware  and  software  parts.  The  main  building  blocks  for  a 
BMS  are  a  computer  and  a  screen,  preferably  a  touch  screen.  Lurthermore,  a  keyboard 
may  be  added  in  order  to  make  it  possible  to  enter  textual  information  into  the  BMS.  The 
BMS  stations  will  be  connected  to  a  GPS  receiver,  in  order  to  acquire  information  about 
the  current  location.  In  the  future,  other  sensors,  like  a  laser  range  finder,  might  be 
connected.  Lor  the  distribution  of  the  information,  the  BMS  uses  combat  net  radio 
communication.  However,  in  more  static  environments,  a  Local  Area  Network  (LAN),  or 
a  wireless  LAN  might  be  used. 

A  team  consisting  of  representatives  from  the  RNLA,  several  software  companies  and 
TNO  Defense  Research  has  been  formed  in  January  1999  and  will  be  continuing  the 
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development  of  the  BMS  until  at  least  the  beginning  of  2002.  Around  mid  2001,  30 
systems  will  be  handed  over  to  the  RNLA.  In  2002,  a  battalion-sized  unit  will  be 
equipped  with  the  BMS.  This  battalion  will  use  the  BMS  during  their  peacekeeping 
operation  in  Bosnia.  The  project  schedule  is  depicted  in  Figure  1 . 


Jan  ‘99 


Start  of 
project 


Figure  1:  Time  schedule 

The  main  goal  of  developing  the  demonstrator  is  not  to  deliver  a  fully  operational  system, 
but  to  define  and  evaluate  the  functional  and  technical  requirements  that  should  be 
imposed  upon  an  operational  BMS.  Another  important  goal  is  to  gain  insight  into  the 
operational  benefits  of  using  a  BMS.  The  final  operational  BMS  will  probably  be 
developed  by  industry.  The  results  of  the  demonstrator  phase  (functional  and  technical 
requirements)  will  form  an  important  input  to  the  procurement  phase. 

Although  there  are  many  issues  related  to  the  development  of  a  BMS,  this  paper  will 
focus  on  the  iterative  approach  that  has  been  adopted  and  in  particular  on  the  active  user 
participation.  To  put  all  things  in  perspective,  the  next  chapter  will  first  describe  the 
environment  in  which  BMS  will  operate  and  the  challenges  that  need  to  be  addressed. 
After  that,  chapter  3  will  be  entirely  devoted  to  the  current  and  future  users  of  the  BMS 
and  in  chapter  4  some  conclusions  are  presented. 

2.  The  world  around  the  BMS 
2.1  Environment 

The  Dutch  BMS  will  be  used  at  the  levels  of  battalion  and  below,  down  to  the  single 
vehicle.  At  each  echelon,  the  BMS  will  be  fitted  into  different  types  of  vehicles,  such  as 
tanks  and  armored  personnel  carriers.  This  means  that  special  attention  needs  to  be  paid 
to  the  harsh  environment  in  which  the  BMS  will  operate. 

Inside  the  vehicles,  it  can  be  cold,  wet,  noisy,  dirty  and  shaky.  Furthermore,  users  might 
wear  gloves  when  operating  the  BMS.  This  imposes  special  constraints  upon  the  design 
of  both  hardware  and  software.  For  example,  the  current  version  of  the  BMS  has  a  touch 
screen  and  very  large  buttons,  in  order  to  make  it  possible  to  operate  the  system  while 
wearing  gloves.  Special  requirements  apply  also  to  reliability  and  user-acceptability  of 
the  BMS. 

The  RNLA  has  also  some  other  C3I  systems  at  her  disposal,  which  have  to  interact  with 
the  BMS.  The  BMS  will  have  to  exchange  information  with  the  Dutch  Integrated  Staff 
Information  System  (ISIS)  for  brigade  and  division-level  and  with  the  Soldier  Digital 
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Assistant  (SDA),  which  is  a  C3I  system  on  a  handheld  computer,  being  developed  for  the 
individual  soldier.  This  is  shown  in  Figure  2. 


Figure  2:  C3I  systems  in  the  RNLA 


In  the  near  future,  a  migration  of  the  C3I  systems  towards  a  so-called  C2  workstation  will 
be  performed.  This  will  be  a  generic  system,  based  on  the  RNLA-C3I-architecture.  The 
C2  workstation  can  have  different  appearances  at  different  echelons,  in  order  to  meet  the 
operational  and  ergonomic  requirements.  The  C2  workstation  enables  a  more  integrated 
and  streamlined  approach  to  C2  on  all  echelons,  from  soldier  to  army  corps.  Re-use  of 
software  components  and  a  more  uniform  way  of  distributing  data  are  two  other 
advantages  of  this  approach. 


2.2  Challenges 

When  developing  a  BMS,  one  encounters  many  challenges.  This  section  describes  some 

of  them. 

1.  Hardware.  The  hardware  that  is  used  for  a  BMS  needs  to  withstand  a  great  deal. 
Since  the  BMS  will  be  built  inside  vehicles,  special  environmental  conditions  might 
occur.  Inside  vehicles,  it  can  be  wet,  cold,  hot,  very  light  or  quite  dark,  and  there 
might  be  a  lot  of  dust  and  dirt.  Furthermore,  since  soldiers  typically  move  around 
inside  their  vehicles,  they  might  bump  into  the  hardware  with  their  boots  or  other 
parts  of  their  gear. 

2.  Fitting  hardware  into  vehicles.  Most  vehicles  are  already  stuffed  with  equipment, 
and  the  personal  gear  of  the  soldiers  is  added  to  that.  In  most  vehicles  it  is  therefore 
difficult  to  find  a  space  for  the  BMS.  Added  to  that  is  the  fact  that  the  BMS  needs  to 
be  in  a  place  where  the  user  can  operate  it  in  a  safe  and  healthy  manner.  It  is  clear  that 
a  screen  that  is  positioned  right  behind  the  head  of  the  user  is  not  very  easy  readable. 
Also  the  incidence  of  light  inside  the  vehicle  can  be  a  limiting  factor  when 
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determining  the  best  location  for  the  BMS.  In  Figure  3,  the  inside  of  a  tracked  vehicle 
is  shown,  while  a  soldier  operates  a  touch  screen. 


Figure  3:  Trying  to  find  the  best  location  for  BMS  inside  a  vehicle 

3.  Data  communication.  All  exchange  of  information  within  the  BMS  network  and 
between  BMS  and  other  C3I  systems  is  handled  through  a  digital  military  radio, 
which  has  a  very  limited  bandwidth.  This  means  that  much  consideration  is  given  to 
the  question  which  data  needs  to  be  distributed  at  which  intervals.  Typically, 
(military)  users  want  as  much  information  as  possible,  but  because  of  the  limited 
bandwidth,  they  have  to  make  a  trade-off  between  diversity  and  timeliness  of 
information.  However,  when  the  staff  of  a  battalion  is  deployed  in  the  field,  there 
sometimes  is  the  possibility  to  use  a  (Wireless)  LAN.  This  means  that  the  available 
bandwidth  is  increased,  and  therefore  more  information  might  be  distributed  within 
the  staff.  Besides  the  limited  bandwidth,  combat  net  radio  communication  is  not 
always  reliable,  and  the  network  might  not  always  be  fully  connected. 

4.  Training.  The  future  users  of  the  BMS  need  to  be  trained  in  using  the  system.  During 
the  past  evaluation  cycles,  the  training  consisted  of  one  day  of  instruction  in  a 
classroom.  In  the  future,  military  instructors  need  to  be  trained,  so  they  can  train  the 
rest  of  the  military  personnel.  Training  involves  more  than  just  knowing  which 
buttons  to  push.  Users  also  need  to  learn  how  to  gain  an  operational  advantage  from 
using  the  BMS. 

5.  Interoperability.  As  stated  before,  the  BMS  is  not  the  only  C3I  system  in  the  RNLA. 
Therefore,  attention  needs  to  be  paid  to  the  integration  between  the  different  systems 
at  the  different  echelons.  Besides  that,  military  operations  these  days  are  very  often 
international,  which  means  that  also  interoperability  between  C3I  systems  from 
different  countries  is  important.  Attention  needs  to  be  paid  both  to  the  technical 
solution  and  to  the  question  which  information  needs  to  be  distributed. 

6.  Functionality.  Since  there  was  no  clear  description  of  what  functionality  a  BMS 
should  contain,  already  at  the  beginning  of  the  project  there  were  many  meetings  with 
the  military.  Since  there  was  also  no  clear  indication  of  the  exact  user  needs,  the 
decision  was  made  to  develop  a  demonstrator.  An  initial  set  of  requirements  was 
drawn  up  before  the  start  of  the  initial  design  and  implementation.  During  the  last  two 
years,  additional  requirements  have  come  up  and  existing  requirements  were 
dismissed.  In  addition  to  the  required  functionality,  military  users  have  to  decide  what 
kind  of  information  they  need. 

7.  Man  machine  interface.  Because  of  the  special  environment  in  which  a  BMS  is 
used,  special  attention  needs  to  be  paid  to  the  man  machine  interface  (MMI).  Many 
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interface  controls  are  hard  to  operate  when  working  with  a  touch  screen,  especially 
while  you  are  inside  a  moving  vehicle.  This  was  the  reason  that  many  controls  could 
not  be  used  in  the  MMI  of  the  BMS.  A  good  example  of  a  control  that  is  hard  to  use 
is  the  well-known  scrollbar.  Scrollbars  are  typically  too  small  to  be  accurately 
positioned,  and  the  entire  concept  of  ‘drag  and  drop’  is  particularly  difficult  when 
using  a  touch  screen.  However,  early  evaluations  and  foreign  experiences  have  shown 
that  using  a  touch  screen  is  still  a  very  good  option.  C3I  systems  that  operate  on 
higher  echelons  do  not  have  these  problems,  because  these  systems  will  be  used  in  an 
environment  that  is  very  similar  to  a  regular  office. 

8.  Evaluations.  At  different  stages  during  the  development  of  the  BMS,  evaluations  are 
carried  out.  With  each  evaluation,  future  users  are  confronted  with  a  not-yet- 
completely-finished  system.  It  is  very  important  to  emphasize  the  importance  of  their 
contribution  to  these  users.  Because  of  their  comments,  the  next  version  of  the  system 
will  be  better  suited  to  the  military  tasks  and  better  suited  to  the  environment  in  which 
it  needs  to  operate. 

Although  the  first  five  challenges  mentioned  above  are  very  interesting  in  themselves, 
this  paper  will  focus  on  the  challenges  six  through  eight.  The  thing  these  three  challenges 
have  in  common  is  that  the  user  is  always  at  the  center  of  interest.  Throughout  this  paper, 
the  emphasis  is  on  the  operational  user,  that  is,  the  user  who  uses  the  BMS  while 
participating  in  a  military  operation.  It  is  well  known  that  there  are  also  other  user  groups, 
such  as  users  who  perform  maintenance  or  configuration  of  the  BMS,  but  these  user 
groups  fall  beyond  the  scope  of  this  paper. 

3.  Using  users 
3. 1  Introduction 

As  stated  before,  the  future  users  of  the  BMS  play  a  very  important  role  in  the 
development  of  the  system.  The  RNLA  has  earmarked  the  13th  mechanized  brigade  as 
‘the  digital  brigade’.  This  brigade  is  involved  in  evaluations  and  will  be  the  first  brigade 
to  actually  utilize  the  operational  BMS. 

The  brigade  has  appointed  a  digitization  liaison  officer  whose  task  it  is  to  coordinate  the 
projects  that  are  related  to  digitization.  This  officer  is  now  also  a  member  of  the  BMS 
team.  Amongst  other  things,  he  is  responsible  for  the  communication  between  the  BMS 
team  and  the  operational  users.  He  also  has  an  important  task  when  it  comes  to  public 
relations,  because  most  users  are  more  impressed  when  an  army  officer  tells  them  about 
BMS  than  when  a  civilian  scientist  tells  the  same  story. 

So  far,  users  have  been  very  enthusiastic  and  cooperative.  This  is  very  important  for  the 
evaluations,  because  enthusiastic  users  will  give  the  most  valuable  comments,  both 
positive  and  negative.  Most  users  try  to  think  along  with  the  developers  and  come  up  with 
good  solutions  for  the  problems  encountered.  The  users  also  supply  suggestions  for  new 
functionality.  Finally,  users  have  been  very  ‘forgiving’  towards  the  BMS.  Apparently, 
they  recognize  the  potential  benefits  of  such  a  system  and  they  trust  that  problems  that 
surface  during  evaluations  will  be  solved  in  due  course. 
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3.2  Approach 

In  order  to  elicit  the  requirements  for  BMS,  an  iterative  approach  is  adopted.  The  reason 
for  this  was  that  at  the  start  of  the  project,  there  was  no  clear  understanding  of  the 
required  functionality.  There  had  been  some  interactions  with  users,  some  foreign 
developments  were  known  and  some  people  had  a  gut  feeling  about  what  a  BMS  should 
do.  One  of  the  activities  that  have  taken  place  at  an  early  stage  was  the  evaluation  of  two 
foreign  BMS’es.  Together  with  a  few  future  users,  scenario’s  were  drawn  up  and  ‘played’ 
afterwards,  while  using  the  system  under  evaluation.  The  result  of  this  evaluation  was  a 
long  list  of  possible  requirements  for  a  Dutch  BMS.  In  contrast  to  the  foreign  systems, 
which  were  especially  developed  for  reconnaissance  and  tanks  respectively,  the  Dutch 
army  wants  to  aim  for  a  generic  BMS,  with  functionality  that  is  useful  for  all  types  of 
units.  At  a  later  stage,  more  specific  functionality  could  be  added. 


From  the  official  start  of  the  project,  in  January  1999,  an  iterative  approach  with 
relatively  short  cycles  was  adopted.  This  made  it  possible  to  develop  the  BMS  in  a 
flexible  way  and  by  evaluating  small  components  of  the  system  at  a  time,  the  users  could 

opment  process  of  the  BMS. 


Figure  4:  development  cycle 


Each  cycle  in  the  adopted  approach  usually  takes  about  four  to  five  months  and  consists 
of  the  following  steps: 

1.  Prioritization  of  requirements.  The  military  representatives  in  the  project  team  are 
actively  involved  in  the  prioritization  of  requirements.  For  each  requirement,  the 
development  team  determines  the  estimated  time  needed  to  implement  the 
functionality.  After  that,  the  user  is  asked  to  participate  in  the  final  prioritization.  The 
motivation  for  assigning  a  high  priority  to  a  specific  functionality  might  be  dependent 
on  the  type  of  evaluation  that  will  be  performed  at  the  end  of  the  current  cycle. 

2.  Design.  The  prioritized  list  leads  to  an  implementation  schedule.  This  schedule 
contains  an  estimate  of  the  time  needed  to  design  and  implement  the  new 
functionality.  When  it  is  clear  what  functionality  is  to  be  added  to  the  BMS  in  the 
current  cycle  (dependent  on  the  available  time),  the  design  phase  starts.  During  this 
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phase,  military  users  frequently  meet  with  designers  and  developers  in  order  to 
explain  and  discuss  the  visual  and  technical  aspects  of  the  new  functionality.  Also  the 
user  interaction  is  defined.  The  result  of  this  phase  is  a  set  of  documents,  that  is,  the 
functional  and  technical  designs.  More  information  about  the  design  of  the  user 
interface  can  be  found  in  section  3.3. 

3.  Implementation.  During  the  implementation  period,  the  military  representatives 
meet  with  the  project  team  every  week  and  look  at  intermediate  versions  of  the  BMS 
and  give  their  first  comments.  Because  of  the  frequent  contact  between  military  users 
and  software  developers,  the  latter  gain  a  better  insight  in  the  purpose  of  the  system 
they  are  developing  and  this  helps  them  to  actively  participate  in  inventing  solutions 
when  problems  occur. 

4.  Testing.  Some  time  before  the  next  evaluation,  usually  four  or  five  weeks,  the 
implementation  is  stopped.  This  moment  is  more  or  less  independent  from  the  results 
that  have  been  achieved  so  far.  This  is  because  the  evaluation  period  has  been  agreed 
with  the  users  from  the  13th  mechanized  brigade  and  cannot  be  rescheduled.  The  next 
few  weeks  are  used  for  testing  the  new  functionality,  the  integration  of  the  new 
functionality  with  the  old  system  and  the  fixing  of  bugs  that  surface. 

5.  Evaluation.  When  a  new  version  is  finished  and  tested,  the  BMS  is  evaluated  during 
an  evaluation  period.  More  detailed  information  about  the  evaluation  is  given  in 
section  3.4. 

6.  Collection  of  new  requirements.  After  that,  all  comments  made  during  the 
evaluation  are  listed  and  the  next  cycle  starts  with  a  new  prioritization. 

3.3  Use  cases 

A  major  part  of  the  development  effort  is  devoted  to  designing  and  implementing  the  man 
machine  interface  (MMI).  All  interactions  with  the  BMS  need  to  be  simple  and  quickly. 
Users  must  be  able  to  operate  the  system  in  every  environment  they  might  find 
themselves  in.  Also  the  system  must  be  easy  to  learn. 

In  designing  the  MMI,  so-called  use  cases  are  frequently  used.  Use  cases  have  their 
origin  in  the  object-oriented  design  world  and  have  proven  to  be  a  very  good  means  of 
communication  between  users  and  developers.  This  is  another  way  in  which  the  users  of 
the  13th  mechanized  brigade  are  involved  in  the  BMS  project.  Use  cases  can  be  seen  as 
small  scenarios  that  describe  the  interaction  between  the  user  and  the  system.  The  use 
cases  are  stated  in  human  language  and  are  reviewed  by  both  military  users  and 
developers.  Very  often,  sketches  of  screen  layouts  are  provided  with  the  use  cases  to  give 
the  users  an  idea  of  what  the  BMS  will  look  like.  Every  use  case  represents  a  task  that  is 
recognizable  by  the  user.  For  example,  one  such  use  case  is  ‘enemy  spot  report’.  This  use 
case  describes  the  actions  the  user  has  to  perform  to  create  an  enemy  spot  report  and  also 
the  appearance  and  actions  of  the  BMS. 

3.4  Evaluations 

Every  four  to  five  months,  the  user  is  asked  to  participate  in  an  evaluation  of  the  BMS 
functionality  that  has  been  developed.  Usually,  each  evaluation  focuses  on  a  specific  part 
of  the  BMS.  For  example,  there  have  been  evaluations  of  the  data  communication,  (parts 
of)  the  MMI  and  the  functionality  for  creating  and  distributing  plans. 
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The  scale  of  the  evaluations  ranges  from  two  single  users  to  the  entire  staff  of  a  battalion 
and  evaluations  were  held  both  in  an  office  environment  and  in  the  field. 

Before  an  evaluation,  the  users  familiarize  with  the  BMS  during  a  one-day  training 
course.  This  training  course  takes  place  in  a  classroom,  where  about  20  students  are 
trained  on  10  BMS  workstations.  Usually,  common  desktop  computers  are  used.  The 
outline  of  the  training  is  as  follows: 

1.  Introduction  and  walk-through  of  the  BMS  interface. 

2.  Exercises  for  the  students  to  perform.  This  gives  them  hands-on  experience  with  the 
interface  and  symbols  that  are  used  in  the  BMS. 

3.  Explanation  of  procedures  concerned  with  creation  and  distribution  of  plans. 

4.  Exercises  for  the  students,  focused  on  the  planning  process.  The  students  follow  the 
entire  process  of  creating  a  plan,  sending  it  to  their  subordinate  commanders  and 
receiving  their  contributions  to  the  plan. 

5.  Time  reserved  for  questions  and  remarks. 

The  evaluation  itself  usually  starts  with  the  BMS  team  crawling  through  armored  vehicles 
to  fit  the  BMS  station  and  other  hardware  parts  into  the  vehicles.  After  that,  the  exercise 
starts  and  the  BMS  team  changes  from  an  executing  to  a  monitoring  role.  When  a 
problem  occurs,  a  specific  member  of  the  team  is  assigned  to  solve  it,  dependent  on  the 
nature  of  the  problem  (data  communication,  software,  and  functionality).  Since  exercises 
typically  are  run  on  a  24-hours  basis,  the  BMS  team  is  also  available  during  the  nights. 

During  the  entire  evaluation,  observers  are  present  who  observe  the  users  while  they 
work  with  the  BMS.  These  observers  come  from  the  TNO  Human  Factors  Institute  and 
have  a  thorough  understanding  of  both  the  BMS  system  and  the  tasks  that  need  to  be 
performed  by  the  military  users.  The  observers  report  their  observations  by  means  of 
observation  checklists.  At  several  specific  moments  during  the  exercise  they  also  hand 
out  questionnaires  for  the  users  to  fill  out.  These  questionnaires  are  very  short  and  easy  to 
fill  out.  It  typically  takes  the  user  less  than  five  minutes  to  complete  them.  At  the  end  of 
the  exercise,  users  are  asked  (or  ordered  by  their  commander)  to  fill  out  a  more  elaborate 
questionnaire.  In  this  questionnaire,  very  detailed  questions  about  the  functionality,  visual 
and  interaction  aspects  need  to  be  answered. 

After  an  evaluation,  a  report  is  written  which  lists  the  observations  that  were  made  by  the 
observers  and  the  users.  Usually,  the  number  of  proposed  alterations  to  the  system, 
deduced  from  the  recorded  observations,  exceeds  the  time  available  before  the  next 
evaluation,  so  a  prioritized  list  of  comments  is  compiled.  This  way,  the  user  will 
experience  in  the  next  evaluation  that  many  of  his  observations  are  addressed.  This  helps 
in  keeping  the  user  motivated  to  take  part  in  the  evaluations. 

The  next  two  sections  describe  evaluations  that  were  performed  in  June  and  October 

2000. 


3.4.1  Evaluation  ‘Digital  Rat’ 

The  evaluation  ‘Digital  Rat’  was  conducted  in  June  2000.  The  objective  of  the  evaluation 
was  to  determine  whether  the  functionality  that  was  implemented  in  the  BMS,  together 
with  the  data  communication  through  the  military  radio,  was  sufficient  to  cover  the  need 
for  Situational  Awareness  of  a  reconnaissance  platoon.  Besides  that,  the  configuration  of 
the  BMS  stations  was  such  that  the  captain  in  charge  with  exercise  control  could  monitor 
the  positions  of  both  the  reconnaissance  platoon  and  the  two  vehicles  that  acted  as 
enemy.  This  enabled  the  exercise  controller  to  coordinate  and  evaluate  the  exercise. 

The  situation  during  the  evaluation  is  depicted  in  Figure  5. 


Figure  5:  Digital  Rat  configuration 


A  reconnaissance  platoon  consists  of  seven  tracked  vehicles, 
BMS  stations  were  mounted  on  top  of  the  vehicles,  next  to  the 
YPR  with  the  computer  on  top  of  it  is  shown  in  Figure  6. 


in  this  case  YPR’s.  The 
commanders’  hatch.  The 


Figure  6:  YPR  with  BMS  station 
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During  the  week  of  the  evaluation,  the  reconnaissance  platoon  had  to  perform  several 
different  tasks.  Amongst  them  were  observing  an  enemy,  guard  an  area  and 
reconnaissance  of  objects  and  routes. 

At  the  end  of  the  evaluation,  the  user  came  to  the  following  conclusions  (only 
conclusions  that  fall  within  the  scope  of  this  paper  are  listed): 

•  Nearly  all  participants  were  very  positive  about  the  development  of  the  BMS  and 
about  the  active  user  participation  during  the  development. 

•  During  the  evaluation,  users  learned  to  trust  the  BMS  more  and  more.  They  made  less 
use  of  the  paper  map. 

•  Especially  in  situations  without  visual  contact  between  the  different  vehicles,  the 
BMS  was  considered  to  increase  the  Situational  Awareness  significantly. 

•  The  frequency  of  position  updates  was  considered  too  low.  Users  want  a  near  real 
time  display  of  the  position  information  (updates  about  every  2  seconds).  The 
bandwidth  of  the  military  radio  is  the  main  bottleneck  here. 

3.4.2  Evaluation  ‘Rhino  Integration’ 

The  evaluation  ‘Rhino  Integration’  was  conducted  in  October  2000.  This  evaluation 
involved  another  command  level,  that  is,  the  staff  of  a  battalion  (the  17th  armored  infantry 
battalion)  and  its  subordinate  units.  The  functionality  to  create  and  distribute  plans  and 
overlays  was  added  to  the  BMS.  The  objective  of  this  evaluation  was  to  determine 
whether  the  plan  functionality  was  suited  for  task  and  to  see  in  what  way  the  staff  of  a 
battalion  would  use  the  BMS. 

The  battalion  staff  consisted  of  ten  vehicles,  some  of  them  armored  personnel  carriers  and 
some  of  them  shelters  loaded  on  trucks.  Each  vehicle  had  two  BMS  stations  inside.  The 
battalion  staff  was  divided  into  three  parts,  which  were  connected  through  a  Wireless 
LAN.  The  three  parts  were  positioned  on  the  exercise  area  with  in-between  distances  of 
50  to  100  meters.  The  subordinate  units  (three  companies,  one  reconnaissance  platoon, 
one  mortar  platoon,  one  section  of  military  engineers  and  one  anti-aircraft  artillery  unit 
were  not  in  the  field,  but  inside  a  building.  The  distance  to  the  exercise  area  was  about  1 
kilometer.  Because  of  the  tight  bushes  and  large  buildings  between  the  subordinate  units 
and  the  exercise  area,  a  special  data  radio  (the  NTDR)  was  used  for  the  communication 
between  these  locations.  The  people  forming  the  subordinate  units  played  the  so-called 
Tower  control’  (LOCON)  and  were  also  operators  of  a  simulation  program  (in  this  case 
KIBOWI,  a  Dutch  system).  The  simulation  program  caused  events,  upon  which  the 
LOCON  units  had  to  respond.  By  means  of  the  BMS  and  the  radio,  they  communicated 
with  the  battalion  staff. 

The  configuration  during  the  evaluation  is  depicted  in  Figure  7. 
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.........  —  Wireless  Local  Area  Network  —  —  =  NTDR  (experimental 

“  —  Local  Area  Network  military  data  radio) 


Figure  7:  Rhino  Integration  configuration 

Also  the  exercise  controllers,  in  this  case  a  small  brigade  staff,  were  in  the  possession  of  a 
BMS,  but  since  they  also  had  to  act  as  exercise  controller  for  two  other  battalions  (which 
did  not  have  the  BMS),  they  did  not  really  use  the  BMS  during  the  exercise. 

Prior  to  the  exercise,  the  initial  plan,  which  consists  of  a  set  of  overlays,  was  entered  into 
the  BMS  by  the  S3  of  the  battalion  staff.  At  the  start  of  the  exercise,  even  before  the  issue 
of  order,  the  battalion  commander  distributed  this  plan  to  his  subordinate  commanders. 
This  enabled  the  subordinate  commanders  to  better  anticipate  the  issue  of  order  and  to 
start  their  own  planning  cycle  sooner. 

During  the  exercise,  which  included  both  a  defensive  and  an  offensive  phase,  the  users 
made  the  following  remarks: 

•  Situational  Awareness  increases  as  a  result  of  using  BMS. 

•  Running  exercises  with  BMS  increases  the  workload  of  the  units,  both  during  the 
preparation  of  the  exercise  and  during  the  exercise  itself.  The  increased  workload 
during  the  exercise  is  amongst  others  a  result  of  the  fact  that  existing  procedures  are 
not  perfectly  fit  to  using  a  BMS.  However,  this  increased  workload  is  acceptable  to 
users,  because  user  involvement  will  lead  to  a  better  BMS  (and  procedures)  in  the 
future. 

•  When  combining  a  BMS  with  other  computer  systems,  effort  must  be  put  into  the 
integration  of  both  systems.  In  this  case,  a  war  game  was  used  to  simulate  the 
behavior  of  the  units.  Because  the  BMS  was  not  integrated  with  this  war  game,  the 
operators  often  had  to  enter  the  same  information  twice. 

•  Working  with  BMS  was  ‘fun’.  Many  users  were  very  interested  in  the  development  of 
this  type  of  new  systems.  Most  users  presented  useful  suggestions  for  extensions  to 
the  BMS  functionality. 

The  figures  below  show  some  impressions  of  the  exercise  Rhino  Integration. 
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Figure  8:  The  command  post  of  the  battalion 


Figure  10:  Engineer  working  with  BMS 


Figure  9:  Users  working  with  BMS  inside  an 
armored  vehicle 


Figure  11:  LOCON  working  with  BMS  and 
war  game 


Figure  12:  Screenshot  of  BMS  during  Rhino 
Integration 


3.4.3  Planned  evaluations 

For  the  future,  there  are  already  two  evaluations  planned.  The  first  one,  called  “Digital 
Fusilier”,  will  be  held  in  the  first  week  of  June  2001  (at  the  time  of  publication  of  this 
paper,  the  evaluation  will  be  already  over).  This  evaluation  will  be  very  similar  to  the 
evaluation  “Rhino  Integration”  The  main  difference  will  be  that  this  time  the  17th 
armored  infantry  battalion  will  have  to  be  more  independent  of  the  BMS  team.  The  BMS 
team  will  observe  the  preparation  and  execution  of  the  exercise,  but  when  there  are  any 
problems,  the  17th  battalion  will  have  to  solve  them  on  their  own.  Only  in  special 
circumstances,  support  from  the  BMS  team  will  be  provided.  This  approach  was  chosen 
in  order  to  ensure  that  the  17th  battalion  is  capable  of  working  with  the  set  of  BMS 
stations  that  will  be  handed  over  to  them  by  mid  2001.  This  will  enable  them  to  do  more 
tests  during  the  rest  of  the  year  2001,  without  having  to  depend  on  the  assistance  of  the 
BMS  team. 


The  second  planned  evaluation  will  take  place  in  the  autumn  of  2001,  in  Bosnia.  During 
this  evaluation,  the  Dutch  units  that  form  SFOR  10  participate  in  a  two-week  test  period 
where  the  BMS  will  be  used  during  a  peacekeeping  operation.  The  goal  of  this  evaluation 
is  to  determine  whether  the  existing  functionality  is  suitable  for  peacekeeping  operations, 
even  though  it  was  developed  with  traditional  article  V  operations  in  mind.  The  second 
goal  of  this  evaluation  is  to  test  the  communication  between  BMS  stations  through 
satellite  communication. 

4.  Conclusions 

The  conclusions  of  making  use  of  users  while  developing  a  BMS  are: 

1.  By  actively  involving  users  in  the  development  of  systems  like  a  BMS,  they  feel  more 
committed  to  the  system.  They  see  the  system  more  as  ‘their  system’  than  just  another 
system  that  was  forced  upon  them  by  some  developers. 

2.  Frequent  contact  between  users  and  developers  leads  to  a  better  understanding  of  the 
tasks  the  system  has  to  perform,  for  both  users  and  developers.  This  enables  the  users 
and  developers  to  actively  participate  in  solving  problems. 
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3.  By  choosing  relatively  short  development  cycles,  there  is  always  a  concrete  goal 
everyone  is  working  towards.  This  goal  will  be  no  more  than  a  few  months  in  time 
away. 

4.  After  each  evaluation,  that  means  every  four  to  five  months,  the  military  users  know 
exactly  what  the  status  of  the  development  process  is.  They  know  what  has  been 
implemented  and  what  not.  Their  expectations  for  the  next  cycle  emerge  from  the 
same  starting  point,  which  makes  ‘expectation  management’  easier.  After  a  few 
cycles,  users  learn  to  estimate  the  amount  of  work  that  can  be  done  within  a 
development  cycle  and  they  more  or  less  know  what  to  expect  in  the  next  evaluation. 

5.  To  people  involved  in  more  traditional  system  development,  the  ‘BMS  approach’ 
seems  slow  and  costly,  because  of  a  large  overhead.  The  time  available  for  real 
software  development  is  limited  compared  to  the  total  time  spent  each  cycle. 
However,  both  BMS  developers  and  users  feel  that  this  is  a  very  good  approach, 
especially  in  projects  where  nobody  knows  exactly  what  the  final  product  will  look 
like. 
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